Many semiconductor designs, both in Integrated Circuit (IC) and in Field Programmable Gate Array (FPGA) applications are constructed in a modular fashion by combining a set of IP cores, such as Central Processing Units (CPUs), Digital Signal Processors (DSPs), video and networking processing blocks, memory controllers and others with an interconnect system. The interconnect system implements the system-level communications of the particular design. The IP cores are typically designed using a standard IP interface protocol, either public or proprietary. These IP interface protocols are referred to as transaction protocols. An example transaction protocol is Open Core Protocol (OCP) from OCP-IP, and Advanced Extensible Interface (AXI™) and Advanced High-performance Bus (AHB™) from Arm Inc. As semiconductor designs have evolved from relatively small, simple designs with a few IP cores into large, complex designs which may contain hundreds of IP cores, the IP core interconnect technology has also evolved.
The first generation of IP core interconnect technology consisted of a hierarchical set of busses and crossbars. The interconnect itself consists mostly of a set of wires, connecting the IP cores together, and one or more arbiters which arbitrate access to the communication system. A hierarchical approach is used to separate high-speed, high performance communications from lower-speed, lower performance subsystems. This solution is an appropriate solution for simple designs. A common topology used for these interconnects is either a bus or a crossbar. The trade-off between these topologies is straightforward. The bus topology has fewer physical wires which saves area and hence cost, but it is limited in bandwidth. The wire-intensive crossbar approach provides a higher aggregate communication bandwidth.
The above approach has a severe limitation in that the re-use of the IP cores is limited. The interfaces of all the IP cores connecting to the same interconnect are required to be the same. This can result in the re-design of the interface of an IP core or the design of bridge logic when a particular IP core needs to be used in another system.
This first generation of interconnect also implements a limited amount of system-level functions. This first generation of IP core interconnect technology can be described as a coupled solution. Since the IP interfaces are logically and physically not independent from each other, they are coupled such that modifying one interface requires modifying all the interfaces.
The second generation of IP interconnect is a partially decoupled implementation of the above described bus and crossbar topologies. In these solutions, the internal communication protocol of the communications system, or transport protocol, is decoupled from the IP interface protocol, or transaction protocol. These solutions are more flexible with regards to IP reuse as in these solutions the semiconductor system integrator can connect IP cores with different interfaces to the same communication system through some means of configurability.
The third generation of IP core interconnect technology is the Network-on-a-chip (NoC) which implements not only decoupling between transaction and transport layers, but also a clean decoupling between transport and physical layers. The key innovation enabling this solution is the packetization of the transaction layer information. The command and data information that is to be transported is encapsulated in a packet and the transport of the packet over the physical medium is independent of the physical layer.
In existing NoC solutions, bursts of information at the transaction layer are converted into packets, which are transported over physical links. A NoC packet is constructed of two parts: a header and a payload. The payload usually includes, but is not limited to, data information, with optionally other data-related information such as byte-enable and/or protection or security information. The header contains two types of information: first, transaction protocol level information that is transferred end-to-end without being changed by the interconnect and secondly, transport protocol level information needed and used by the interconnect to transport the payload correctly from one IP core to another through the interconnect. The term “correctly” does not refer only to routing, but also implies meeting other system level requirements, such as latency, quality of service, bandwidth requirements, etc.
In many transaction layer protocols, the command and data information of the transaction in a burst are presented in the same clock cycle. In the conversion process from transaction layer to transport layer, the header is created and used as the first one of several words in the packet. This packetization may insert one or more cycles of latency since the header is transported over the physical links during one or more clock cycles before the data is transported.
While an IP core can be re-used from design to design, the implementation of a NoC is likely to change as the NoC implements the system-level communications which are design specific. The number of IP cores, latency, bandwidth, power, and clock-speed are some of the variables that impact the requirements on the NoC. Hence, mechanisms have been developed to automate the design of an instance of a NoC to rapidly construct a NoC instance. During instantiation of a NoC, the width of the link, and therefore the width of the packet, is configurable by the user and this configurability allows the user to make an optimal trade-off between the number of wires in the interconnect system, latency and bandwidth.
In existing NoC solutions, the configurability that is available in the construction of a packet is limited to the selection of a value of one parameter. Using this single-parameter, a packet width can be selected. The values of the width of the packet and the latency penalty due to the header of the packet are intrinsically linked. Accordingly, a change in value of the packet width parameter can result in additional latency insertion.